WebAssembly WASIファイルディスクリプタ仮想化：ユニバーサルなリソース抽象化を解放する

急速に進化する分散コンピューティングの世界では、セキュアで、高い移植性を持ち、かつ非常に効率的なアプリケーションの追求が最重要課題となっています。世界中の開発者やアーキテクトは、異種のオペレーティングシステム、多様なハードウェアアーキテクチャ、そして堅牢なセキュリティ境界の絶え間ない必要性によってもたらされる課題に取り組んでいます。この世界的な課題が、WebAssembly（Wasm）とそのシステムインターフェースであるWASI（WebAssembly System Interface）を、強力なパラダイムシフトとして台頭させました。

WASIの革新の中心には、ファイルディスクリプタ仮想化として知られる洗練されたメカニズムがあります。これは、ユニバーサルなリソース抽象化という約束を支える概念です。このブログ記事では、この重要な側面に焦点を当て、WASIが仮想ファイルディスクリプタを活用してホスト固有の詳細を抽象化し、それによってWebAssemblyモジュールが基盤となるインフラストラクチャに関係なく、非常に安全で、ポータブルで、効率的な方法で外部世界と対話できるようにする方法を説明します。

永続的な課題：コードと具体的なリソースの橋渡し

WASIのソリューションを分析する前に、それが対処する根本的な問題を理解することが不可欠です。ソフトウェアアプリケーションは、その複雑さに関わらず、必然的に外部リソースと対話する必要があります。これには、ファイルの読み書き、ネットワークを介したデータの送受信、現在時刻の取得、乱数の生成、環境変数のクエリなどが含まれます。従来、これらの対話は、オペレーティングシステム（OS）カーネルが提供する特定の関数であるシステムコールを介して実行されていました。

「ネイティブ」のジレンマ：OS固有のインターフェースと内在するリスク

CやRustで書かれたプログラムがファイルにデータを保存するケースを考えてみましょう。Linuxシステムでは、open()、write()、close()といったPOSIX標準関数を使用するかもしれません。一方、Windowsシステムでは、CreateFile()、WriteFile()、CloseHandle()といったWin32 APIを使用します。この明確な違いは、一方のOS用に書かれたコードが他方で実行されるためには、大幅な修正や全く異なる実装が必要になることが多いことを意味します。この移植性の欠如は、グローバルなユーザー層や多様なデプロイメント環境をターゲットとするアプリケーションにとって、多大な開発および保守のオーバーヘッドを生み出します。

移植性の問題に加えて、システムコールへの直接アクセスは重大なセキュリティ脆弱性をもたらします。OSの全範囲のシステムコールへの無制限のアクセスを許可された悪意のある、あるいは侵害されたアプリケーションは、以下のような行為を行う可能性があります：

• システム上の任意のファイルにアクセス：機密性の高い設定ファイルを読み取ったり、重要なシステムバイナリに悪意のあるコードを書き込んだりする。
• 任意のネットワーク接続を開く：サービス拒否（DoS）攻撃を開始したり、データを外部に漏洩させたりする。
• システムプロセスを操作する：重要なサービスを終了させたり、新しい不正なプロセスを生成したりする。

仮想マシン（VM）やコンテナ（Dockerなど）といった従来の封じ込め戦略は、一定の分離層を提供します。しかし、VMは大きなオーバーヘッドを伴い、コンテナはより軽量であるものの、依然として共有カーネルリソースに依存しており、「コンテナエスケープ」や過剰な権限アクセスを防ぐためには慎重な設定が必要です。これらはプロセスレベルでの分離を提供しますが、WasmとWASIが目指すような、きめ細かいリソースレベルでの分離は必ずしも提供しません。

「サンドボックス」の必須要件：実用性を犠牲にしないセキュリティ

サーバーレスプラットフォーム、エッジデバイス、ブラウザ拡張機能など、現代の信頼できない、あるいはマルチテナント環境では、はるかに厳格で粒度の細かい形式のサンドボックス化が求められます。目標は、コード片が意図した機能を実行できるようにしつつ、明示的に必要としない不必要な権力やリソースへのアクセスを一切与えないことです。この最小権限の原則として知られる原則は、堅牢なセキュリティ設計の基本です。

WebAssembly (Wasm)：ユニバーサルなバイナリフォーマット

WASIの革新についてさらに深く掘り下げる前に、WebAssembly自体について簡単に振り返りましょう。Wasmは、高性能アプリケーション向けに設計された低レベルのバイトコード形式です。いくつかの魅力的な利点を提供します：

• ポータビリティ： Wasmバイトコードはプラットフォームに依存しません。つまり、基盤となるCPUアーキテクチャやオペレーティングシステムに関係なく、Wasmランタイムを持つ任意のシステムで実行できます。これはJavaの「一度書けば、どこでも実行できる」に似ていますが、はるかに低いレベルで、ネイティブに近いパフォーマンスを実現します。
• パフォーマンス： Wasmはネイティブに近い実行速度を目指して設計されています。Wasmランタイムによって高度に最適化されたマシンコードにコンパイルされるため、CPU集約型のタスクに最適です。
• セキュリティ： Wasmはデフォルトで安全なメモリセーフのサンドボックス内で実行されます。Wasmランタイムから明示的に許可されない限り、ホストシステムのメモリやリソースに直接アクセスすることはできません。
• 言語非依存： 開発者は、さまざまな言語（Rust、C/C++、Go、AssemblyScriptなど）で書かれたコードをWasmにコンパイルでき、言語固有のランタイム依存なしで多言語開発が可能です。
• 小さなフットプリント： Wasmモジュールは通常非常に小さいため、ダウンロードが速く、メモリ消費量が少なく、起動時間も短縮されます。これはエッジ環境やサーバーレス環境で非常に重要です。

Wasmは強力な実行環境を提供しますが、本質的に隔離されています。ファイル、ネットワーク、その他のシステムリソースと対話するための組み込み機能を持っていません。ここでWASIが登場します。

WASI：WebAssemblyとホストシステムを精密に橋渡しする

WASI、すなわちWebAssembly System Interfaceは、WebAssemblyモジュールがホスト環境と安全に対話できるようにするための、標準化されたAPIのモジュール式コレクションです。OSに依存しないように設計されており、Wasmモジュールがブラウザの外で真のポータビリティを達成することを可能にします。

システムインターフェースの役割：対話のための契約

WASIを標準化された契約と考えてください。WASI仕様に準拠して書かれたWasmモジュールは、システムリソースを要求するためにどの関数を呼び出すことができるか（例：「ファイルを開く」、「ソケットから読み取る」）を正確に知っています。Wasmモジュールをホストし実行するWasmランタイムは、これらのWASI関数を実装し、抽象的なリクエストをホストOS上の具体的な操作に変換する責任を負います。この抽象化レイヤーがWASIの力の鍵です。

WASIの設計原則：ケイパビリティベース・セキュリティと決定性

WASIの設計は、ケイパビリティベース・セキュリティに大きく影響されています。Wasmモジュールが特定のアクション（例：「すべてのファイルアクセス」）を実行するための包括的な許可を持つ代わりに、特定のリソースに対する特定の「ケイパビリティ」のみを受け取ります。これは、ホストがWasmモジュールに、限られたリソースセットに対して必要な権限だけを明示的に付与することを意味します。この原則により、攻撃対象領域が劇的に最小化されます。

もう一つの重要な原則は決定性です。ブロックチェーンや再現可能なビルドなどの多くのユースケースでは、Wasmモジュールが同じ入力を与えられた場合に常に同じ出力を生成することが不可欠です。WASIは、システムコールの振る舞いを明確に定義し、可能な限り非決定性を減らすことで、これを促進するように設計されています。

ファイルディスクリプタ仮想化：リソース抽象化への深掘り

さて、本題に入りましょう。WASIがファイルディスクリプタ仮想化を通じてリソース抽象化をどのように実現しているかについてです。このメカニズムは、WASIが約束するセキュリティとポータビリティの中心です。

ファイルディスクリプタとは何か？（従来の視点）

従来のUnixライクなオペレーティングシステムでは、ファイルディスクリプタ（FD）は、ファイルやその他の入出力リソース（パイプ、ソケット、デバイスなど）にアクセスするために使用される抽象的なインジケータ（通常は非負整数）です。プログラムがファイルを開くと、OSはファイルディスクリプタを返します。その後、プログラムはこのFDを使用して、そのファイルに対するすべての後続操作（読み取り、書き込み、シークなど）を行います。FDは、プロセスが外部世界と対話する方法の基本です。

Wasmの観点から見た従来のFDの問題点は、それらがホスト固有であることです。あるOS上のFD番号は、別のOS上では全く異なるリソースに対応するか、あるいは無効である可能性があります。さらに、ホストのFDを直接操作すると、サンドボックス化が回避され、Wasmモジュールに無制限のアクセスが与えられてしまいます。

WASIの仮想ファイルディスクリプタ：抽象化レイヤー

WASIは、仮想ファイルディスクリプタという独自の概念を導入しています。WASIでコンパイルされたWasmモジュールがファイルやネットワークソケットと対話する必要がある場合、ホストOSのファイルディスクリプタと直接対話することはありません。代わりに、WASIで定義されたAPI（例：wasi_snapshot_preview1::fd_read）を使用してWASIランタイムにリクエストを行います。

その仕組みは以下の通りです：

1. ホストによる事前オープン： Wasmモジュールが実行を開始する前に、ホスト環境（Wasmランタイム）はモジュール用に特定のディレクトリやリソースを明示的に「事前オープン」します。例えば、ホストはWasmモジュールが特定のディレクトリ、例えば/my-data内のファイルにのみアクセスでき、読み取り専用アクセスを許可すると決定するかもしれません。
2. 仮想FDの割り当て： 事前オープンされた各リソースに対して、ホストは仮想ファイルディスクリプタ（整数）を割り当てます。これは*Wasmモジュールのサンドボックス内でのみ*意味を持ちます。これらの仮想FDは通常3以上です。FD 0、1、2は慣例的に標準入力、標準出力、標準エラー用に予約されており、これらもWASIによって仮想化されます。
3. ケイパビリティの付与： 仮想FDとともに、ホストはその仮想FDに対する特定のケイパビリティ（権限）のセットも付与します。これらのケイパビリティは粒度が細かく、Wasmモジュールがそのリソースに対して実行できるアクションを正確に指定します。例えば、あるディレクトリは仮想FD（例：3）とread、write、create_fileのケイパビリティで事前オープンされるかもしれません。別のファイルは仮想FD 4とreadケイパビリティのみで事前オープンされるかもしれません。
4. Wasmモジュールの対話： Wasmモジュールがファイルから読み取りたい場合、wasi_snapshot_preview1::path_openのようなWASI関数を呼び出し、事前オープンされたディレクトリの1つからの相対パス（例：仮想FD 3に対する"data.txt"）を指定します。成功した場合、WASIランタイムは新しく開かれたファイルに対して*別の*仮想FDを、その特定のケイパビリティと共に返します。モジュールはその後、この新しい仮想FDを読み書き操作に使用します。
5. ホストによるマッピング： ホスト上のWasmランタイムはこれらのWASIコールをインターセプトします。仮想FDを検索し、要求されたアクションが付与されたケイパビリティと一致するかを検証し、その後、この仮想リクエストを、事前オープンされたリソースがマッピングされている実際の基盤となるホストファイルディスクリプタを使用して、ホストOS上の対応する*ネイティブ*なシステムコールに変換します。

このプロセス全体は、Wasmモジュールに対して透過的に行われます。Wasmモジュールは、自身の抽象的で仮想的なファイルディスクリプタと、それに関連付けられたケイパビリティのみを見て操作します。ホストの基盤となるファイルシステムの構造、ネイティブなFD、または特定のシステムコールの規約については一切関知しません。

具体例：ディレクトリの事前オープン

画像を処理するために設計されたWasmモジュールを想像してみてください。ホスト環境は、次のようなコマンドでそれを起動するかもしれません：

wasmtime --mapdir /in::/var/data/images --mapdir /out::/tmp/processed-images image-processor.wasm

このシナリオでは：

• ホストのWasmランタイム（例：Wasmtime）は、2つのホストディレクトリ/var/data/imagesと/tmp/processed-imagesを事前オープンします。
• /var/data/imagesをWasmモジュールの仮想パス/inにマッピングし、例えばreadとlookupのケイパビリティを付与します。これは、Wasmモジュールが自身の仮想/inディレクトリ内のファイルをリスト表示し、読み取ることができることを意味します。
• /tmp/processed-imagesをWasmモジュールの仮想パス/outにマッピングし、例えばwrite、create_file、remove_fileのケイパビリティを付与します。これにより、Wasmモジュールは処理済みの画像を自身の仮想/outディレクトリに書き込むことができます。
• Wasmモジュールは、/in/picture.jpgを開くように要求されると、そのファイルに対する仮想FDを受け取ります。その後、その仮想FDを使用して画像データを読み取ることができます。処理が完了し、結果を保存したい場合、/out/picture-processed.pngを開き、別の仮想FDを受け取り、それを使用して新しいファイルを書き込みます。

Wasmモジュールは、ホスト上の/inが実際には/var/data/imagesであることや、/outが/tmp/processed-imagesであることを全く知りません。それは、自身のサンドボックス化された仮想ファイルシステムについてのみ知っています。

グローバルなエコシステムへの実践的な影響と利点

WASIのファイルディスクリプタ仮想化の素晴らしさは、単なる技術的な優雅さをはるかに超えています。それは、グローバルに多様な技術的ランドスケープで活動する開発者や組織にとって、深遠な利点を解き放ちます：

1. 比類なきセキュリティ：最小権限の原則の実践

これは、間違いなく最も重要な利点です。明示的なホストによる事前オープンとケイパビリティの付与により、WASIは最小権限の原則を厳格に実施します。Wasmモジュールは、与えられたものに正確にしかアクセスできません。以下のことはできません：

• 指定されたディレクトリから脱出する： /dataにアクセスするはずのモジュールが、突然/etc/passwdを読み取ろうとすることはできません。
• 不正な操作を実行する： 読み取り専用アクセスを与えられたモジュールは、ファイルを書き込んだり削除したりすることはできません。
• 明示的に付与されていないリソースにアクセスする： 事前オープンされていなければ、アクセス不可能です。これにより、多くの一般的な攻撃ベクトルが排除され、信頼できないソースからであってもWasmモジュールをはるかに安全に実行できるようになります。このレベルのセキュリティは、異なるユーザーのコードが同じインフラストラクチャで実行されるサーバーレスコンピューティングのようなマルチテナント環境にとって非常に重要です。

2. 強化されたポータビリティ：一度書けば、本当にどこでも実行可能

Wasmモジュールは純粋に抽象的な仮想ファイルディスクリプタとWASI API上で動作するため、基盤となるホストオペレーティングシステムから完全に切り離されます。同じWasmバイナリを、以下のような環境でシームレスに実行できます：

• Linuxサーバー（wasmedge、wasmtime、またはlucetランタイムを使用）。
• Windowsマシン（互換性のあるランタイムを使用）。
• macOSワークステーション。
• エッジデバイス（Raspberry Piや、特殊なランタイムを備えたマイクロコントローラなど）。
• クラウド環境（さまざまな仮想マシンやコンテナプラットフォーム上）。
• カスタム組込みシステム（WASI仕様を実装したもの）。

ホストランタイムが、WASIの仮想FDとパスからネイティブOSコールへの変換を処理します。これにより、開発工数が大幅に削減され、デプロイメントパイプラインが簡素化され、アプリケーションを再コンパイルや再設計なしで最適な環境にデプロイできるようになります。

3. 堅牢な分離：横方向の移動と干渉の防止

WASIの仮想化は、Wasmモジュールとホストの間、および同時に実行されている異なるWasmモジュール間に強力な分離境界を作成します。あるモジュールの不正な振る舞いや侵害が、システムの他の部分や他のモジュールに容易に広がることはありません。これは、複数の信頼できないプラグインやサーバーレス関数が単一のホストを共有するシナリオで特に価値があります。

4. 簡素化されたデプロイメントと設定

世界中の運用チームにとって、WASIはデプロイメントを簡素化します。各アプリケーションに固有のボリュームマウントやセキュリティコンテキストを持つ複雑なコンテナオーケストレーションを設定する必要なく、Wasmランタイムの呼び出し時に明示的なリソースマッピングとケイパビリティを定義するだけで済みます。これにより、より予測可能で監査可能なデプロイメントが可能になります。

5. 向上した構成可能性：安全で独立したブロックからの構築

WASIによって提供される明確なインターフェースと強力な分離により、開発者はより小さく独立したWasmモジュールを組み合わせて複雑なアプリケーションを構築できます。各モジュールは分離して開発およびセキュリティ保護され、その後、リソースアクセスが厳密に制御されていることを理解した上で統合できます。これは、モジュラーアーキテクチャ、再利用性、および保守性を促進します。

実践におけるリソース抽象化：ファイルを超えて

「ファイルディスクリプタ仮想化」という用語はファイルのみに焦点を当てているように聞こえるかもしれませんが、WASIのリソース抽象化は他の多くの基本的なシステムリソースにも及びます：

1. ネットワークソケット

ファイルと同様に、WASIはネットワークソケット操作も仮想化します。Wasmモジュールは任意のネットワーク接続を勝手に開くことはできません。代わりに、ホストランタイムは明示的に以下の許可を与える必要があります：

• 特定のローカルアドレスとポートにバインドする： 例：ポート8080のみ。
• 特定のリモートアドレスとポートに接続する： 例：api.example.com:443のみ。

Wasmモジュールはソケットを要求し（仮想FDを受け取る）、ホストランタイムが実際のTCP/UDP接続を管理します。これにより、悪意のあるモジュールが内部ネットワークをスキャンしたり、外部攻撃を開始したりするのを防ぎます。

2. クロックとタイマー

現在時刻へのアクセスやタイマーの設定も、WASIが抽象化する対話の一つです。ホストはWasmモジュールに仮想クロックを提供し、モジュールはホストのハードウェアクロックと直接対話することなく時刻をクエリしたりタイマーを設定したりできます。これは決定性を確保し、モジュールがシステム時刻を操作するのを防ぐために重要です。

3. 環境変数

環境変数には、しばしば機密性の高い設定データ（例：データベースの認証情報、APIキー）が含まれています。WASIは、ホストがすべてのホスト環境変数を公開するのではなく、必要な環境変数*のみ*をWasmモジュールに明示的に提供することを可能にします。これにより、情報漏洩を防ぎます。

4. 乱数生成

暗号学的に安全な乱数生成は、多くのアプリケーションにとって不可欠です。WASIは、Wasmモジュールがランダムなバイトを要求するためのAPIを提供します。ホストランタイムは、高品質で安全に生成された乱数を提供する責任を負い、ホストの乱数ジェネレータの仕様（例：Linuxの/dev/urandomやWindowsの`BCryptGenRandom`）を抽象化します。

世界的な影響と変革的なユースケース

WebAssemblyのパフォーマンスとポータビリティ、そしてWASIの安全なリソース抽象化の組み合わせは、世界中の多様な産業でイノベーションを推進する準備が整っています：

1. エッジコンピューティングとIoT：制約のあるデバイス上のセキュアなコード

エッジデバイスはしばしばリソース（CPU、メモリ、ストレージ）が限られており、潜在的に安全でない、または信頼できない環境で動作します。Wasmの小さなフットプリントとWASIの強力なセキュリティモデルは、エッジデバイスにアプリケーションロジックをデプロイするのに理想的です。AI推論用のWasmモジュールを実行するセキュリティカメラを想像してみてください。そのモジュールはカメラのフィードからの読み取りと、処理済みデータを特定のネットワークエンドポイントに書き込むことのみが許可され、他のシステムアクセスは一切ありません。これにより、AIモジュールが侵害されたとしても、デバイス自体は安全なままであることが保証されます。

2. サーバーレス関数：次世代のマルチテナンシー

サーバーレスプラットフォームは本質的にマルチテナントであり、共有インフラストラクチャ上でさまざまなユーザーのコードを実行します。WASIは、このユースケースにおいて従来のコンテナよりも優れたサンドボックスメカニズムを提供します。その高速な起動時間（小さなサイズと効率的な実行のため）と粒度の細かいセキュリティにより、ある関数のコードが別の関数や基盤となるホストに干渉できないことが保証され、クラウドプロバイダーと開発者にとってサーバーレスのデプロイメントがより安全で効率的になります。

3. マイクロサービスと多言語アーキテクチャ：言語非依存のコンポーネント

組織はますますマイクロサービスを採用しており、それらはしばしば異なるプログラミング言語で書かれています。事実上あらゆる言語からコンパイルされたWasmは、これらのサービスのユニバーサルランタイムになることができます。WASIの抽象化により、Rustで書かれたWasmサービスがGoで書かれたサービスと同じくらい簡単かつ安全にファイルやデータベースと対話できることが保証され、しかもインフラストラクチャ全体でポータブルであるため、世界規模での多言語マイクロサービスの開発とデプロイメントが簡素化されます。

4. ブロックチェーンとスマートコントラクト：決定的で信頼性の高い実行

ブロックチェーン環境では、スマートコントラクトは多数の分散ノードで決定的かつ安全に実行されなければなりません。Wasmの決定論的な性質とWASIの制御された環境は、スマートコントラクト実行エンジンとして優れた候補となります。ファイルディスクリプタ仮想化により、コントラクトの実行が分離され、ノードの基盤となるファイルシステムと対話できないことが保証され、完全性と予測可能性が維持されます。

5. 安全なプラグインと拡張システム：アプリケーションの機能を安全に拡張

Webブラウザからコンテンツ管理システムまで、多くのアプリケーションがプラグインアーキテクチャを提供しています。サードパーティのコードを統合することは常にセキュリティリスクを伴います。プラグインをWASI対応のWasmモジュールとして実行することで、アプリケーション開発者は各プラグインがアクセスできるリソースを正確に制御できます。例えば、写真編集プラグインは、与えられた画像ファイルの読み取りと変更版の書き込みのみが許可され、ネットワークアクセスやより広範なファイルシステム権限は与えられないかもしれません。

ユニバーサルな抽象化への課題と将来の方向性

WASIのファイルディスクリプタ仮想化とリソース抽象化は絶大な利点を提供しますが、エコシステムはまだ進化の途上にあります：

1. 進化する標準：非同期I/Oとコンポーネントモデル

初期のWASI仕様であるwasi_snapshot_preview1は、主に同期I/Oをサポートしており、これはネットワークを多用するアプリケーションにとってパフォーマンスのボトルネックになる可能性があります。現在、非同期I/Oとより堅牢なWasm用コンポーネントモデルを標準化する取り組みが進められています。コンポーネントモデルは、Wasmモジュールを真に構成可能で相互運用可能にすることを目指しており、お互いの内部詳細を知ることなく安全かつ効率的に通信できるようにします。これにより、リソース共有と抽象化の能力がさらに強化されるでしょう。

2. 詳細な仮想化におけるパフォーマンスの考慮事項

Wasm自体は高速ですが、WASIコールとネイティブシステムコールの間の変換レイヤーは、ある程度のオーバーヘッドを導入します。非常に高性能なI/Oバウンドのアプリケーションでは、このオーバーヘッドが考慮事項になるかもしれません。しかし、Wasmランタイムの継続的な最適化とより効率的なWASI実装により、このギャップは絶えず縮小しており、要求の厳しいシナリオでもWasm + WASIは競争力を持つようになっています。

3. ツールとエコシステムの成熟度

WasmとWASIのエコシステムは活気に満ちていますが、まだ成熟の途上にあります。より優れたデバッガ、プロファイラ、IDE統合、そして異なる言語間での標準化されたライブラリが、採用を加速させるでしょう。より多くの企業やオープンソースプロジェクトがWASIに投資するにつれて、世界中の開発者にとってツールはさらに堅牢で使いやすいものになるでしょう。

結論：次世代のクラウドネイティブおよびエッジアプリケーションを強化する

WebAssembly WASIのファイルディスクリプタ仮想化は、単なる技術的な詳細以上のものであり、現代のソフトウェア開発におけるセキュリティ、ポータビリティ、およびリソース管理へのアプローチにおける根本的なシフトを表しています。ホスト固有の対話の複雑さとリスクを抽象化する、ユニバーサルでケイパビリティベースのシステムインターフェースを提供することにより、WASIは開発者が、本質的により安全で、小さなエッジデバイスから巨大なクラウドデータセンターまであらゆる環境にデプロイ可能で、最も要求の厳しいワークロードにも十分な効率を持つアプリケーションを構築することを可能にします。

多様なコンピューティングプラットフォームの複雑さに取り組む世界中の人々にとって、WASIは魅力的なビジョンを提供します。それは、コードが真にどこでも、安全に、そして予測可能に実行される未来です。WASI仕様が進化し続け、そのエコシステムが成熟するにつれて、この強力な抽象化を活用して、より回復力があり、革新的で、普遍的にアクセス可能なソフトウェアソリューションを構築する新世代のクラウドネイティブ、エッジ、および組込みアプリケーションの登場が期待されます。

WebAssemblyとWASIの画期的なリソース抽象化アプローチで、安全でポータブルなコンピューティングの未来を受け入れましょう。真にユニバーサルなアプリケーションデプロイメントへの旅は順調に進んでおり、ファイルディスクリプタ仮想化は、この変革的な動きの礎石です。